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(54) Method for nfianaging multicast addresses for transmitting and receiving multimedia 

conferencing information on an internet protocol (IP) network implemented over an ATM 
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(57) In a multicast capable IP network (102) imple- 
mented over an ATM network, each client tenninal on a 
multimedia conference, for each media type It transmits, 
Is assigned a mutticast IP address and a port number 
(together known as a socket) on which to transmit pack- 
ets, wherein. each assigned multicast IP address is 
unique and different than the multicast IP address as- 
signed to any other client for any media type. Each client 
terminal then selects, tor each media type, which clients 
on the conference it wants to receive packets from. Only 
packets that are in fact requested by a client are routed 
over the mutticast IP network to the requesting client. A 
single special purpose Multicast Address Resolution 
System (MARS) server is associated with the confer- 
ence when the conference is established. Each client 
terminal uses that MARS sen/er, whether on the same 
or different I P sub-networks, but on a common ATM net- 
work, for purposes of mapping the mutticast IP address- 
es used in the conference into a set of unicast ATM end- 
point addresses used by the ATM-connected client ter- 
minals. Similarty, when a specific conference uses a 
Multicast Server, a single special purpose Multicast 
Sender is used for all clients on the conference, whether 
on the same or different IP sub-networks, for purposes 
of establishing point-to-muttipoint ATM connections to 
the conference endpoints. 
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Description *- • 

invention relates to data communications, and more 
particularly, to the real-time interactive distribution of 
multlrDedia information using the multicast Internet Pro- 
tocol (IP) which is implemented over an ATM network. 

Background of the Invention 

Multimedia conferencing systems are typically 
characterized by the following: a directory servk;e which 
lists the set of conferences; a dynamic mechanism for 
keeping track of the members of a conference as they 
join or leave the conference; tools for generating and 
processing the audb, video and data sharing compo- 
nents of a conference; a data network for interconnect- 
ing the members of a conference; and transport mech- 
anisms for distributing the multimedia conference con- 
tent among the conference members. 

Different transport mechanisms can be used to in- 
terconnect partrcipants depending on the underlying ca- 
pabilities of the data network. Two basic communication 
capabilities are: unicast communicatkxi, meaning a 
point-to-point communicatkxi between a source and a 
destinatkxi endpoint; and muttbast communication, 
meaning that one source endpoint reaches multiple des- 
tination endpoints. Since conferencing inherently im- 
plies the possibility of more than one destination end- 
point, if the network is capable only of unk:ast commu- 
nicatk)n, then either the source must create multiple uni- 
cast connections, or Multicast Servers extemal to the 
network must be employed. In the former case, each 
sender of informatwn sets up multiple connectkjns to 
every receiver, and repricates the data on each connec- 
.'tion. Each receiver has multiple incoming connections, 
one for every sender of informatkxi. This approach be- 
comes inefficient as the number of partcipants (N) gets 
large for two reasons. Firstly, the number of network 
connections is proportkxial to the square of N. Secondly, 
each endpoint needs to replk^ate the data N times, pos- 
sibly leading to both an excessive and unnecessary use 
of bandwidth in the network and an excessive amount 
of computatkxi at the source. If external Multicast Serv- 
ers are empbyed, then these servers perform the data 
replicatbn function. Each sender of information needs 
to have a single unbast connectbn to the Multbast 
Server. Each receiver is connected to the Multbast 
Server. The number of connectbns is proportional to N, 
as all senders share the same set of connectbns to the 
set of receivers. The disadvantage of this scheme is that 
the Multicast Server becomes a bottleneck when N gets 
large. 

When the interconnection network is multicast ca- 
pable, more efficient attemattves are possible. With mul- 
ticast servbe, the source of the information sends the 
data only once - the replication is handled by the net- 
work. It is as if the Multicast Servers described in the 
previous paragraph are bundled into the network. Effi- 



cient technkfuesfor replicatkMi rnay exist in the network. 
For example, the data replicatbn can be performed in 
hardware, and the replication functbn can be distributed 
over the switches or routers of the network. Furthermore 

s the replication topotogy may be very efficient, e.g. a 
spanning tree, where receivers are leafs of the tree, and 
the data source is the root of the tree. Note that rt is also 
possible to use extemal Multbast Servers in conjunctbn 
with a multicast network. For example, the Multicast 

TO Sender may be connected to the receivers by multicast 
mechanisms, and to the sources by unbast mecha- 
nisms. 

The Internet Protocol (IP) is a wkJely used transport/ 
networking protocol. In the IP Application Programming 

IS Interface (API) (known as IP sockets or Wl NSOCK), ap- 
plbatbn programs may write data to, or read data from 
a so-called socket just as rf the socket was a file de- 
scriptor' on the local computer. A socket is linked to a 
pair of numbers, i.e. an IP address and a positive integer 

^ referred to as a port number. For sending, the IP address 
used is the destination address to be placed in the des- 
tination fiekl IP packet header, and the port number to 
be used by the applicatbn process on a remote nnachine 
for receiving the data. For receiving, the IP address is 

2S implicitly the bcal rr^chine address (or in the case of IP 
multicast, the multicast group address of Interest) , and 
the port number to be used by the application process 
on the tocal machine for receiving the data. 

Multicast IP, the primary mechanism by ^ich IP 

30 networks support multbast, is an emerging capability of 
the IP protocol. In I P multbast service, unlike the unicast 
IP service where the address represents a specific and 
unique end-system, a sender transmits data addressed 
to an abstractbn called a multicast address group. In 

35 the prbr art, for a given conference, each media-type 
(e.g., audb, vbeo) is associated with a particular port 
number and multicast IP address. All receivers for the 
given media-type listen to the specific socket consisting 
of the known multbast IP address and port number All 

40 senders for the given media-type send to the specified 
socket consisting of the same multicast IP address and 
port number. Among different media-types, a different 
socket is utilized to enable different applbatbn pro- 
grams to handle the different media of the conference. 

4S In prbr art systems, the multicast IP address may be the 
same or different among media types, but the port 
number is alnrx>st always different. 

Receivers find out about the existence of multicast 
groups and port numbers through various (centralized 

so or distributed) directory mechanisms. For example, a 
well-known multicast IP address may be reserved for 
directory announcements. Alternatively, a centralized 
sender may contain a list of multicast groups and distrib- 
ute this list to client terminals upon request. Once the 

ss appropriate multicast IP address informatbn has been 
obtained from the directory mechanism, receivers send 
messages to Multicast Server processes (e.g., in multi- 
cast routers) indicating that they want to join a partbular 
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• t . .group. The routers then exchange information about the 
set of users that want to communicate, and build up in- 
terconnection trees among themselves. Note that In the 
prior art, for a given media typo, since a common mul- 
ticast IP address is used by ail senders and receivers in 
a conference, and since the multicast IP address is the 
atomic unit of routing, this Implies that the transmissions 
of all senders get routed to all receivers, even if each 
receiver is Interested in a (possibly different) subset of 
the senders. This requires the receiver's application pro- 
gram to receive, process, and discard unwanted infor- 
mation; furthermore the typically expensive network 
bandwidth required to transport the unwanted informa- 
tion is wasted. 

Receivers communicate with multicast routers over 
some sub-network technotogy to which both are at- 
tached, such as, for example, Ethernet, France Relay, 
or ATM. When IP multicast is supported over a sub-net- 
work that has a native multicast ability with a similar 
sen^ice capability to that of IP (e.g., Ethernet), multicast 
IP addresses may be mapped directly onto Ethernet ad- 
dresses. Each terminal on the Ethernet then listens tor 
those multicast Ethernet addresses that it is interested 
in, and Ignores the rest. 

When IP multicast is supported over a virtual circuit 
oriented sub-network, such as ATM, that does not have 
a native multicast capability similar to IP, it is necessary 
to have an address resolution mechanism to map a mul- 
ticast IP address into a set of unicast ATM addresses. 
In the prbr art, a Multicast Address Resolution System 
(MARS) server is utilized for this purpose. When IP re- 
ceivers want to join an IP multicast group, they send a 
message to the MARS server. The MARS server then 
informs all senders to the IP multicast group of the kJen- 
tity of the new -receivers. In the prior art, however, a 
MARS sender is only associated with a static set of IP 
endpotnts that are specific to a single sub-network. 
Thus, rt a receiver is a member of a local sub-network, 
the MARS server specific to that sub-network Is used. 
If conference members are on different sub-networks, 
one approach of the prior art is to fonward multicast IP 
packets via IP multicast routers connecting the different 
sub-networks. With respect to the sub-networic of which 
a sender is a member, the multicast router is treated as 
another receiver by the MARS server of the sender's 
sub-network. With respect to the sub-networks in which 
a receiver is a member, the multicast router is treated 
as a sender by the MARS sen/er of the receiving sub- 
network. Each sub-network thus requires a separate 
MARS server and there are no interactksns between the 
plural MARS servers. If it can be assumed that the send- 
ers and receivers are attached to a common ATM net- 
work, the prtor art imposes an extra layer of protocol 
processing and packet forwarding that introduces addi- 
tional delays and unnecessary bandwidth utilizatbn. 
One way ot avokJIng the use of multicast routers in this 
context is to allow the MARS servers in the different sub- 
networks to communicate directly with one another in 



. kJentifying the ATM addresses of senders and receivers 
in the different sub-networks. Such multiple MARS sew- 
ers thus need to communk:ate with each other for con- 
trol and coordination purposes, which also requires sig- 
s nificant overhead and signaling there between, and the 
establishment of an inter^erver protocol. 

Summary ot the Invention 

10 In accordance with the present invention rather than 
using the fixed plural MARS senders associated with 
each individual IP sub-network, a single special purpose 
MARS server is associated with a particular conference 
at the time theconference is established. All participants 

IS of a particular conference, whether on the same or dif- 
ferent IP sub-networks, but on a common ATM network, 
use this same special purpose MARS server for that 
conference. Thus, the need for communk:ation among 
eitherthe set of plural MARS servers ormultk:a5t routers 

20 is eliminated. 

When a conference is established, a Directory 
Server albcates from the then available and unused 
multicast IP addresses, a set of such addresses to be 
used for the conference based on the maximum number 

^ of expected participants, which number is provided by 
a conference originator. As each participant jdns the 
conference, the partcipanrs client temninal is assigned 
a port number and multicast IP address on whk^ to 
transmit for each media type, wherein the multicast IP 

30 address is from the set of multbast IP addresses alb- 
cated for use by that conference. In this manner, by 
choosing to receive on only selected multimedia ad- 
dresses and port numbers, each client terminal receives 
transmisskxis for each media type from only those client 

35 terminals it desires. 

As it joins the conference, each client is also pro- 
vided with the ATM address of the single special pur- 
pose MARS server assigned for use for that specific 
conference when the conference was originated. Each 

40 client then configures its IP-over-ATM interface to use 
that specific MARS server for the mapping of the con- 
ference multicast IP addresses to ATM addresses. Fur- 
ther, if the specific conference also uses a Multicast 
Sender (MCS), the ATM address of a single special pur- 

45 pose MCS used for the conference is also provkJed to 
each client as it joins the conference. 

Brief Description of the Drawings 

50 FIG. 1 isablockdiagramshowingapluralityof client 
terminals connected to a multicast capable IP net- 
work over a common ATM network, to which is also 
connecteda Directory Sender for establishing a con- 
ference, and a single special purpose MARS server 
ss and single special purpose Multicast Server in ac- 
cordance with the present invention; 
FIG. 2 is a chart illustrating the steps associated 
with establishing a conference by a conference 
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. - . originator on the network of. 

FIG. 3 is a chart illustrating the steps associated 
with a user joining an already established confer- 
ence on the network o1 FIG. 1 ; 
FIG. 4 is a chart illustrating the interactive steps be- 
tween a client terminal and a single special purpose 
M/^S server when the client terminal joins an ex- 
isting conference; and 

FIG. 5 is a chart illustrating the interactive steps be- 
tween a client terminal and the special purpose 
MARS server and a special purpose Multicast Serv- 
er, when a Multicast Sender is also employed in the 
conference. 

Detailed DescrlptlcMi 

With reference to FIG. 1 , multimedia client terminals 
101-1 - 101-5 are connected to a multicast capable In- 
ternet Protocol (IP) data network 102 implemented over 
a comnrKxi ATM network comprising ATM switches 103, 
104 and 105, and ATM interconnecttons 120, 121 , and 
122. Each of the client terminals 101-1 - 101-5 is con- 
nected to the IP network 102 over ATM. Each client ter- 
minal 101-1-101-5 has a unique ATM unlcast erKfpoint 
address. Network 1 02 comprises plural IP sub-networks 
110, 111, and 112. TTius. as illustrated in FIG. 1, client 
terminals 101-1 and 101-2 are members of common IP 
sub-network 110 clients terminals 101-3 and 101-4 are 
member of IP sub-network 111, and client temninal 101-5 
is a member of IP sub-network 112. IP sub-networks 
110, 111 aTKJ 112 are interconnected through multicast 
capable IP routers 1 1 3 and 1 1 4. A Directory Server (DS) 
106, which need not operate in a multbast fashion, is 
connected to the IP network through router 107, which 
need not be multicast capable. 

A single special purpose MARS sender 126 is also 
connected to network 1 02 through ATM switch 1 03. The 
f unctksn of this MARS sender is, for a particular confer- 
ence, to maintain the mapping of the par1k:utar multbast 
IP addresses used by that specific conference to the 
possibly changing set of ATM unicast addresses of the 
conference client terminals. 

Directory Sender 106 functions to maintain a list of 
multicast IP addresses and ports available for use for a 
plurality of different and possibly concurrent conferenc- 
es, to assign a subset of those addresses and ports to 
a partcular conference when a conference is initiated, 
and to assign from that subset a unique multicast IP ad- 
dress and port number to each media type of each client 
as that client makes a request to become a member of 
that conference. Once each socket (multicast IP ad- 
dress and port number) is assigned to a partbular client 
for each media type for use during a conference, the 
assigned multicast IP addresses are marked as being 
unavailable and cannot be assigned to any other client 
attempting to join that same conference. Once a partc- 
ipant departs a still ongoing conference, the muttk:ast 
IP addresses assigned to that participant's client are 



marked as being available and can be-assigned to the 
client of a later joining participant. Directory Sender 106 
also assigns the ATM address of the special purpose 
MARS ssn/er 1 26 to be used by the ATM client terminals 
5 on the conference. 

Upon receiving the set of sockets assigned to it for 
the conference, the client may decide how it wants to 
interact in the conference. Specifically, for each media 
type the client may only want to only receive, or to both 
receive and transmit, or to just transmit. Further, the cli- 
ent may choose to receive a particular media type from 
only select other clients on the conference. When a con- 
ference is established and a client joins an established 
conference, therefore, it receives a list of sockets used 
for transmitting by the other clients associated with the 
conference. At any time during the conference, it may 
then receive packets from the other clients in the con- 
ference on the sockets assigned for transmission to 
those other clients, or it may choose not to receive pack- 
ets of any or all media types from other clients by either 
not adding the other client's socket(s) to its Multicast Re- 
ceive Address List (MRAL), or by deleting the other cli- 
ent's socket from its MRAL if it was previously receiving 
transmissions from the other client. The client then sets 
its local interface to receive only those packets whose 
multicast IP addresses/port numbers match the ones in 
its MRAL Also, upon receiving the ATM address of the 
special purpose MARS sender 126 assigned to the con- 
ference, each client sets up a virtual circuit to this MARS 
sender. During the conference, each client will access 
this MARS server at its ATM address to map the multi- 
cast I P addresses used in the conference to the appro- 
priate set of ATM endpoint addresses. 

In FIG. 1, for example, the conference may com- 
prise the client terminals 101-1 - 101-5. Once the con-- 
ference is established by the conference originator on 
Directory Server 1 06, each client terminal is able to con- 
nect to each other client terminal through a combinatbn 
of queries to MARS server 126, and the setting up of 
point-to-muttipoint virtual circuits via ATM signaling. For 
example, if client terminals 1 01 -4 and 101-5 each wants 
to receive the video transmitted by client terminal 101-1, 
client terminals 1 01 -4 and 101 -5 register their ATM uni- 
cast addresses with MARS sen/er 126, which then as- 
sociates those ATM unicast addresses with the multi- 
cast IP address that client terminal 1 01 -1 uses for vdeo 
transmission. When client terminal 101-1 transmits, 
therefore, it sends the multicast IP address on which it 
transmits its video to MARS server 126 and receives 
therefrom the list of ATM unicast addresses to which 
ATM connectktfis should be established. Client terminal 
101-1 then sets up a point-to-muttipoint virtual circuit to 
the ATM addresses of client terminals 1 01 -4 and 1 01 -5. 
If, during an ongoing conference, client terminal 101-3 
deckJes it also wants to receive the vkJeo signal being 
transmitted by client terminal 1 01 -1 , it sends a message 
to MARS server 126 indicating that it wants to join the 
multicast group (i.e., receive transmissions destined to 
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the particular rnulticast IP address to which client termk- 
nal 101-1 Is ttBnsmming). MARS server 126 then adds 
the ATM address of client terminal 101-3 to the list of 
ATM addresses associated with that multicast IP ad- 
dress on which client terminal 101-1 transmits its video 
signal. Further, MARS server 126 sends an indication 
to client terminal 101-1 to add client terminal 101-3 to 
the previously established poinl-to-muttlpoint ATM vir- 
tual circuit. If, during a conference, one of the clients 
already receiving the video transmissions from client 
terminal 101-1 (such as client terminal 101-4) decides 
that It no longer wishes to receive those transmissions, 
it then sends a message to MARS sender 126 indicating 
that it wishes to leave the multicast group (i.e., no longer 
wants to receive transmissions destined to that particu- 
lar multicast IP address to which client terminal 101-1 is 
transmitting). MARS server 126 then sends an indica- 
tion to client terminal 101 -1 to remove client 101 -4 from 
the previously established point-to-multipoint ATM vir- 
tual circuit. 

It has been assumed above that each transmitting 
client terminal sets up its own point-to-muttipoint ATM 
virtual circuit for each media type to each client terminal 
that wants to receive that media type. The resulting large 
number of point-to-multipoint ATM virtual circuits could 
exhaust switch virtual channel identifier resources. Ac- 
cordingly, an ATM Mufticast Server (MCS) is sometimes 
employed in a conference in order to share point-to- 
muttipoint connections. Transmitters then set up a uni- 
cast point-to-point ATM virtual circuit to the MCS, which 
in tum establishes a point-to-multipoint ATM virtual cir- 
cuit to each client terminal desiring to receive transmis- 
sions. Thus, all transmitters ultimately share the Multi- 
cast Sewer's point-to-muttipoint virtual circuit thereby 
reducing the demand on ATM switch virtual channel 
identifier resources. In the prior art multiple of such Mul- 
ticast Servers may be deployed such that each sub-net- 
worit has its own Multicast Sender. As previously de- 
scribed with respect to per-sub-network prior art MARS 
servers, inter-subnetworic communication between end- 
points in different sub-networits requires the use of mul- 
ticast routers. As before, if it can be assumed that the 
senders and receivers are attached to a common ATM 
network, the prbr art use of multicast routers imposes 
an extra layer of protocol processing and packet for- 
warding that introduces additk>nal delays and unneces- 
sary bandwidth utilization. In accordance with the 
present invention, if an MCS is used within the confer- 
ence, the Directory Server also provides each client with 
the ATM address of a single special purpose Multicast 
Server for use in that specific conference. Each client 
then configures its IP-over-ATM interface to use that 
specific special purpose MCS for all point-to-multipoint 
ATM communication. 

With reference again to FIG. 1, special purpose 
MCS 130 is shown connected to network 102 through 
ATM switch 103. For purposes of an example, it can 
again t>e assumed that the conference comprises client 



— terminals 101-1 - 101-5. If client tenminals-1 01 -4-and-- 
101-5 each wants to receive the video transmitted by 
client terminal 101-1, terminals 101 -4 and 101-5 register 
their ATM unicast addresses with MARS server 126. 

s which then associates those ATM unicast addresses 
with the multicast IP address that client terminal 101-1 
uses for transmission. When client terminal 101-1 is 
ready to transmit, it sets up an ATM virtual circuit to MCS 
130. When client terminal 101-1 transmits, it sends the 

10 multicast IP address on which it transmits its video to 
MARS server 1 26. MARS server 1 26 then sends the list 
of ATM unicast addresses to which ATM connectons 
need to be established to MCS 1 30. MCS 130 then sets 
up a point-to-multipoint virtual circuit to the ATM ad- 

J5 dresses of clients 101-4 and 101-5. Client terminal 
101-1 then transmits to MCS 130 akxig the previously 
established ATM virtual circuit. When a client joins an 
on-going conference or leaves an ongoing conference, 
there is a simitar intenactbn between MARS sender 126 

20 and MCS 130. 

With reference to FIG. 2, the steps to originate a 
conference by an ATM connected conference originator 
are detailed. At step 201 , by sending a packetized mes- 
sage, a user contacts the Directory Sen/er to create a 

2S conference. This coukJ be accomplished by the user 
clicking on an icon on a browser running on the client, 
or by the user inputting a particular URL address. At step 
202, the Directory Sender requests the authorization of 
the user as a conference originator. At step 203, the user 

30 provides his or her ID plus a password. At step 204. if 
recognized by the DS as an authorized conference orig- 
inator, the user is authenticated and permitted to pro- 
ceed to establish the conferertce. If not, the process 
ends at step 209. If authenticated, at step 205, the Di- 

35 rectory Sen/er returns to the user, for example, an 
HTML-formatted page requesting information from the 
originator such as the name and descriptkm of the con- 
ference, the media types involved with the conference, 
the types of encoding used by each of the media types, 

40 the time at which the conference is scheduled to take 
place and its expected duration, the nrmimum number 
of participants, a list of valid participants, and the name 
and phone number of a contact point for the proposed 
conference. The user provides the requested informa- 

4S tion at step 206. At step 207, the Directory Server re- 
tums to the conference originator a password to be used 
by the participants in order to join the conference and 
allocates a set of multicast IP addresses and port num- 
bers from the space of available multk^ast IP addresses 

so and port numbers for each media type. In addition, the 
ATM address of the particular single special purpose 
MARS server that will be used for this conference is re- 
tumed. Further, if a single special purpose Multicast 
Server is to be used for this specific conference, the 

ss ATM address of this MCS is also returned by the Direc- 
tory Sender. At step 208, the Directory Server marks the 
assigned multicast IP addresses as being unavailable 
for assignment to any other conference, and the asso- 
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ciations of the specific -^conference -with .the. addresses.- 
of the assigned MARS server and the MCS. if the latter 
is used. 

Once the confererwe originator has established the 
conference with the Directory Sewer, users at the client s 
terminals may join the conference within its scheduled 
time. With reference to FIG. 3, at step 301, a potential 
ATM connected conferee contacts the DS by sending a 
packetized request either by clicking on an icon or in- 
putting the URL address of the DS on the client's brows- io 
er. At step 302, the client receives from the DS a list of 
ongoing conferences from which the user selects the 
conference to which he or she then wants to join. At step 
303, in response to the selected conference, the DS 
sends a form back to the user's client requesting the us- is 
er's ID and the password assigned by the DS to the con- 
ference. It is assumed that the password is made avail- 
able to the conferees by an external system, such as a 
phone call/message, or encrypted e-mail. The user in- 
puts the requested inf onmatbn and, at step 304, the DS 
compares the inputted informatktn with its list of valid 
conference partk;ipants as inputted by the conference 
originator, and the password established for the confer- 
ence. If the user is not authenticated at step 305, he or 
she is precluded from joining the conference and the 2S 
process ends at step 310. If authenticated at step 305, 
the DS provides at step 306, a mutticast IP address and 
port number for each media type for the client terminal 
to transmit on and a list of sockets for each media type 
to receive on for the other client terminals which are par- 30 
ticipating in the conference and for which the user is a 
valid recipient. In addition, the DS provides the ATM ad- 
dress of the single spec»l purpose MARS server as- 
signed to the conference and the single special purpose 
Multicast Server, if the latter is being used. At step 307, 35 
the user selects those clients from which to receive each 
media type from the list of sockets on which the other 
clients are transmitting. This is done by either adding 
each such other client's address to its MRAL or deleting 
such other client's address from its MRAL if it has been 40 
previously receiving a currently unwanted media type of 
transmission from that other client When a client elects 
to exit a conference, it deletes all the addresses /ports 
associated with the conference from its MRAL When 
the conference is concluded, the Directory Sender, at 4S 
step 309, marks the addresses and ports assigned to 
the conference as available so they can be assigned to 
another conference. 

FIG. 4 illustrates the interactive steps between a cli- 
ent tenninal and the special purpose MARS server when so 
the client terminal wants to join an existing conference 
for the case where a Multicast Server is not used for the 
conference. After the client terminal receives from the 
Directory Sender the multicast IP addresses and port 
numbers on which to receive the other participants' ss 
transmissrons for which it is a valid receiver, and the 
ATM address of the special purpose MARS server to be 
usedfor the conference {step 306 in FIG. 3), at step 401 , 



the client updates its local MARS table. The local MARS — w. . 
table enables the client to be simultaneously associated 
with plural conferences. For each conference, the set of 
assoc^ted multicast IP addresses is in tum associated 
with the ATM address of the MARS server used for that 
conference. At step 402, for each endpoint and media 
type from which it wants to receive transmissbns on the 
existing conferertce that it is joining, the client issues a 
MARS-JOIN message indicating the multicast IP ad- 
dress/port number associated with that endpointAnedia 
type. At step 403, the special purpose MARS server up- 
dates a local table containing the list of ATM endpoints 
that are members of each IP multicast group to include 
the requesting client. At step 404. the MARS senrer then 
instructs the other transmitting members of the existing 
conference to add the new client for each media type 
requested by the client. Each of these other client ter- 
minals thus adds the new client as a leaf to its respective 
distribution tree. The new client, from that point on. can 
receive all transmisskxis associated with the multimedia 
conference whk;h it has selected and tor whch it has 
been validated. At step 405, the MARS sender adds the 
new client as a leaf of the control channel, which is the 
mechanism by which the MARS server sends messages 
to the merrtbers of the conference group. It is through 
this mechanism that the new client can receive subse- 
quent messages about the existence of new group 
members or the deletion of existing group members. 

FIG. 5 illustrates the interactive steps between a cli- 
ent terminal, the special purpose MARS server and the 
special purpose Multicast Server v^en the client termi- 
nal wants to join an existing conference for the case 
where a Multfcast Server is used for the conference. In 
this case, there is little advantage to employing multiple 
multicast IP addresses for different senders. It can be 
assumed that for a given media type, a single mutticast 
IP address is used by all senders. As in FIG. 4, the client 
receives from the Directory Server the multicast IP ad- 
dresses and port numbers on which to receive the other 
participants' transmissions for which it is a valid receiver, 
and the ATM address of the special purpose MARS 
server to be used for the conference, as well as, for this 
case, the ATM address of the particular Mutticast Sender 
to be used for this conference (from step 306 in FIG. 3). 
At step 501 , the client updates its kx^al table listing the 
ATM addresses of the MARS servers and Multicast 
Sen/ers corresponding to the sets of multicast IP ad- 
dresses for that conference. At step 502, for each media 
type from whk;h it wants to receive transmissions, the 
client issues a MARS-JOIN message indicating the mul- 
ticast IP address/port number associated with that me- 
dia type. At step 503, the MARS server updates a kx:al 
table containing the list of ATM endpoints that are mem- 
bers of each IP multicast group. At step 504, the special 
purpose MARS sewer then instructs the special pur- 
pose Multicast Server to add the new client as a leaf of 
its distribution tree corresponding to the multicast ad- 
dresses of the conference. From this point on the new 
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-client is able to recerve all transmissions associated with • 
the multimedia conference which is has selected and for 
which it has been validated. 

Advantageously, by linking a specific conference to 
a specific single special purpose MARS server, and, 
where employed, a singe special purpose Multicast 
Server, the scalability of the conferencing system is im- 
proved. Thus, as a new conference is created, an addi- 
tional MARS server or MCS can be added for the new 
conference. Further, by enabling the use of different 
MARS servers for different conferences, the possibility 
is eliminated that members of one conference may ac- 
cidentally get information pertaining to a different con- 
ference. 

Although described above in the context of IP over 
ATM networks, the present inventkxi can be applied to 
other switched virtual circuit technok>gies such as, for 
example. IP over ISDN, IPoverX.25, and IP over Frame 
Relay. Further, the network need not have a native point- 
to-multipoint capability. In such a case, the point-to- 
muttipoint connection would be via the Multicast Server 
and the connection from the Multicast Server to the end- 
points would consist of plural point-to-point connections. 
Also, the emptoyment of a sin gle special purpose MARS 
sender dedicated to a specific set of IP multicast groups 
has applicability to any IP Multicast over ATM system, 
not just multimedia conferencing. Also, although de- 
scribed in connectkx) with a system in whch each client 
is assigned a different multicast IP address on which to 
transmit, the present invention does not require such ar- 
rangement and can be empbyed in a system which us- 
es a different algorithm for assigning sets of multicast 
addresses to a given conference. 

The above-described embodiment is illustrative of 
the principles of the present inventkxi. Other embodi- 
ments could be devised by those skilled In the art without 
departing from the spirit and scope of the present inven- 
tion. 



Claims 

1. In a multicast capable IP network comprising plural 
IP sub-networks Implemented over a common 
switched virtual circuit in whk^h during a conference 
at least one of a plurality of clients at an associated 
unicast endpoint address transmits packets for mul- 
ticast transmisston to at least some of the plurality 
of clients in the conference at their respective uni- 
cast endpoint addresses using multicast IP ad- 
dresses to transmit on and receive over, a method 
comprising: 

assigning a single special purpose Multicast 
Address Resolution System (MARS) server con- 
nected to the network for use for that conference for 
managing mapping between the multicast IP ad- 
dress to which said at least one of said plurality of 
clients transmits packets and the unicast endpoint 



, - .^.-addresses of each- of -the at- least some of the plu- 
rality of clients receiving such transmitted packets. 

2. The method of claim 1 wherein the conference is a 
5 multimedia conference in whk:h packets of plural 

media types are transmitted by the at least one cli- 
ent on different multicast IP addresses and the spe- 
cial purpose MARS sender manages mapping for 
each media type between the multicast IP address 
10 to which said at least one of said plurality of clients 
transmits packets of that media type and the unicast 
endpoint addresses of each of the at least some of 
the plurality of clients receiving transmitted packets 
of that media type. 

IS 

3. The method of claim 2 wherein the plural media 
types are at least one of audio, video and/or data. 

4. The method of claim 1 wherein the virtual circuit net- 
20 work is an ATM network, the clients are connected 

to the ATM network via ATM, and the endpoint ad- 
dresses are ATM addresses. 

5. The method of claim 2 wherein the special purpose 
25 MARS server maintains for each multicast IP ad- 
dress a set of the unicast endpoint addresses of 
tliose clients on the conference which are currently 
receiving transmissions on that multk^ast IP ad- 
dress 

30 

6. The method of claim 1 further comprising the step 
of assigning a single special purpose Multicast 
Server connected to the network for use for that 
conference for establishing point-to-multipoint con- 

35 nections to the'Clients at their unicast endpoint ad- 
dresses. 

7. The method of claim 2 further comprising the step 
of assigning to each client in the conference for 

40 each media type a different unque muttfcast IP ad- 
dress on which to transmit packets. 

8. The method of claim 7 wherein the multicast IP ad- 
dresses assigned to the clients in the conference 

45 are from a group of multicast I P addresses alfc)cated 
to the conference. 

9. In a multicast capable IP network comprising plural 
IP sub-networks implemented over a common 

so switched virtual circuit on which packets are trans- 
mitted by a plurality of clients on multicast IP ad- 
dresses for multicast transmission, a method for a 
client at a unicast endpoint address to join a con- 
ference and receive transmissions from at least one 

55 other client in the conference at another unicast 
endpoint address, the method comprising the steps 
of: 
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- — providing-to 4h8 -joining client an endpoint ad- -.^ — 
dress ot a single special purpose Multicast Ad- 
dress Resotutton System (MARS) server as- 
signed for use for the conference, which MARS 
server maintains for each multicast IP address s 
a set of all the unicast endpoint addresses of 
those clients on the conference which receive 
transmissions on that multicast IP address; 
receiving a request from the joining client to re- 
ceive transmissions from the at least one other io 
client; and 

adding, in the single special purpose MARS 
server, the unicast endpcHnt address of the join- 
ing client to a group ot endpoint addresses as- 
sociated with the particular multicast IP ad- is 
dress on which the at least one other client 
transmits. 

10. The method of claim 9 further comprising the step 

of instructing the at least one other client to add the 20 
joining client as an additional endpoint on a point- 
to-multipoint virtual circuit to the group of endpoint 
addresses to which the at least one other client 
transmits on the particular multicast IP address. 

2S 

11 . The method of claim 9 wherein the conference is a 
multimedia conference in which packets of plural 
media types are transmitted by the at least one oth- 
er client on different multicast IP addresses, and the 
request from the joining client includes a request to 30 
receive transmissions from the at least one other 
client of packets of at least one of the plural media 
types. 

12. The method of claim 11 wherein the plural media 3S 
types are at least one of audio, video and/or data. 

13. The method of claim 11 further comprising the step 
of assigning to the joining client, for each media type 

for which packets are transmitted, a multicast iPad- 40 
dress on which to transmit such packets that is dif- 
ferent and unique from any multicast IP address as- 
signed to any other client on the conference. 

14. The method of claim 13 wherein the multicast IP ad- 
dresses assigned to the joining client are from a 
group of multicast IP addresses alkx:aled to the 
conference. 

15. The method of claim 9 wherein the virtual circuit net- so 
work is an ATM network, the joining client and the 
other clients are connected to the ATM network via 
ATM, and the unicast endpoint addresses are ATM 
addresses. 

55 

16. The method of claim 9 further comprising the steps 
of: 



■providing to the-joining client an endpoint ad- 
dress of a single special purpose Multicast 
Server assigned for use for the conference, 
which Multicast Server establishes point-to- 
muttipoint connections to clients in the confer- 
ence; 

establishing a virtual connection between the 
joining client and the special purpose Multcast 
Sewer; 

providing the endpoint address of the joining 
client to the Multicast Server; and 
adding the endpoint address of the joining cli- 
ent to the Multicast Server's poinl-to-multipoint 
connections. 
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FIG. 2 



( START ) 



USER CONTACTS DS TO CREATE CONFERENCE 
BY SENDING PACKETIZED MESSAGE 



DS REQUEST AUTHORIZAHON OF USER 
AS CONFERENCE ORIGINATOR 



USER PROVIDES ID PLUS PASSWORD 



USER AUTHENTICATED ? 



YES 



DS RETURNS HTML-FORMAnED PAGE 
REQUESTING NAUE AND DESCRIPTION OF CONFERENCE, 
MEDIA TYPES, TYPE OF ENCODING, TIME AND 
DURATION OF CONFERENCE, MAXIMUM NUMBER 
OF PARTICIPANTS, UST OF VAUD PARnCIPANTS 
AND CONTACT POINT 



USER PROVIDES REQUESTED INFORMATION 



T 



DS RETURNS A PASSWORD TO BE USED BY 
PARHCIPANTS TO JOIN CONFERENCE AND A SET 
OF MULTICAST IP ADDRESSES FROM SPACE OF 

UNUSED ADDRESSES AND PORT NUMBERS FOR EACH 
MEDIA TYPE AND THE ATM ADDRESSES OF MARS 

SERV ER TO BE USED AND MULTICAST SERVER(IF USED) 

\ 



DS MARKS ASSIGNED ADDRESSES AND PORTS 
UNAVAILABLE, AND THE ASSOCIATION OF 
CONFERENCE WITH ADDRESSES OF ASSIGNED MARS 
SERVER AND MULTICAST SERVER (IF USED ) 



QnO 
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FIG. 3 




CstarT ) 



POTENTIAL CONFEREE CONTACTS OS 
BY SENDING PACKEnZED REQUEST 



E 



USER RECEIVES UST OF 
AND SELECTS C0^ 


ONGOING CONFERENCES 
FERENCE TO JOIN 






. DS SENDS FORM BACK 1 
AND PASSWORD FOR < 


rO USER REQUESTING ID 
ILECTED CONFERENCE 



DS AUTHENTICATES USER AS A VAUD 
PARTOIPANT FOR SELECTED CONFERENCE 



^SER AUTHENnCATEDl > 



EH 



DS PROVIDES IP MULTICAST ADDRESSES AND PORT NUMBERS 
FOR USER'S CLIENT TERMINAL TO TRANSMIT ON AND UST OF 
OF SOCKETS FOR EACH MEDIA TYPE FOR OTHER PARTICIPANTS 
IN THE CONFERENCE TO RECEIVE ON AND ATM ADDRESSES OF 
MARS SERVER TO USE AND MULTICAST SERVER (IF USED) 



USER SELECTS CUENTS FROM WHICH TO RECEIVE 
EACH MEDIA TYPE FROM UST OF SOCKETS ON WHICH 
OTHER CLIENTS ARE TRANSMITnNG BY EHHER ADDING 
A CLIENTS ADDRESSES TO ITS MRAL OR DELEHNG ITS 
ADDRESSES FROM ITS MRAL, IF PREVIOUSLY RECOVING 
FROM THAT CLIENT 

I 



USER AT CUENT EXITS CONFERENCE AND CUENT 
DELETES ALL ADDRESSES ASSOCIATED 
WITH CONFEREN CE FROM MRAL 

1 



AT CONCLUSION OF CONFERENCE. DS MARKS ADDRESSES AND 
PORTS PREVIOUSLY ASSIGNED TO CONFERENCE AS UNUSED 

^'P— rEND~) 
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FIG. 4 



(from step 306 IN FIGj) 



CUENT UPDATES HS LOCAL TABLE ASSOCIAHNG 
ATM ADDRESS OF MARS SERVER WITH MULHCAST 
IP ADDRESSES USED IN CONFERENCE 



CLIENT ISSUES MARS- JOIN REQUEST FOR 
DESIRED ENDPOINTS AND MEDIA TYPES 



MARS SERVER UPDATES LOCAL TABLE 
USHNG MEMBERS OF EACH GROUP 



MARS SERVER ISSUES AOD-NEW-CUENT 
DIRECTIVE FOR ALL DESIRED 
ENDPOINTS/MEOIA TYPES 



MARS SERVER ADDS NEW CLIENT 
TO CONTROL CHANNEL 
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FIG. 5 



(from step 306 IN FIG.3) 



CUENT UPDATES HS LOCAL TABLE ASSOCIAnNG 
ATM ADDRESSES OF MARS SERVER AND MULHCAST 
SERVER WITH MULHCAST IP ADDRESSES 
USED IN CONFERENCE 



CUENT ISSUES MARS-JOIN REQUEST FOR 
DESIRED ENDPOINTS AND MEDIA TYPES 



MARS SERVER UPDATES LOCAL TABLE 
LISTING MEMBERS OF EACH GROUP 



MARS SERVER ISSUES ADD-NEW-CLIENT DIRECTIVE 
TO MULTICAST SERVER 
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